USING INDIVIDUALIZED APIs TO BLOCK AUTOMATED ATTACKS ON NATIVE APPS AND/OR PURPOSELY EXPOSED APIs

ABSTRACT

An API call filtering system filters responses to API call requests received, via a network, from user devices. The API call filtering system is configured to require personalized API call requests wherein each API call (except for some minor exceptions) includes a unique endpoint identifier (“UEID”) of the user device making the request. Using the UEID, the web service or other service protected by the API call filtering system can be secured against excessive request iterations from a set of rogue user devices while allowing for ordinary volumes of requests of requests the user devices, wherein one or more boundaries between what is deemed to be an ordinary volume of requests and what is deemed to be excessive request iterations are determined by predetermined criteria.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to pendingU.S. application Ser. No. 14/327,461, entitled “USING INDIVIDUALIZEDAPIs TO BLOCK AUTOMATED ATTACKS ON NATIVE APPS AND/OR PURPOSELY EXPOSEDAPIs,” filed Jul. 9, 2014. The application herein claims the benefit ofpriority from all of the above listed patent applications and herebyincorporates by reference in their entirety the said patentapplications.

FIELD OF THE INVENTION

The present invention relates generally to network computer systemsecurity and more particularly to defense against some automated attackson the network computer system.

BACKGROUND

The Internet (and related networks) can be used to send e-mails, conductbusiness, automate machinery and data processing. Connected users canuse the Internet to interact with other connected users and/or connectedcomputer systems. Some of the Internet traffic is wanted by the partiesinvolved, but other traffic is unwanted by at least one party. Forexample, by some estimates, more than three quarters of daily e-mailvolume over the Internet is unwanted by its targeted recipient(sometimes referred to as “spam”). More than just e-mail traffic isunwanted by its targeted recipient. For example, banks, bank customers,and bank network operators and managers do not want traffic that isattempting to manipulate the bank's online banking system to facilitatefraud. Of course, in today's world, there is some traffic that is wantedand/or necessary, so one task that online systems operators have to dealwith is separating the wanted traffic from the unwanted traffic, lettingthe wanted traffic through and blocking the unwanted traffic.

For example, the typical e-mail recipient does not want to receive allunsolicited commercial offers. The online network operator that limitsaccess to resources to authorized users does not want to receive trafficfrom unauthorized users. Unfortunately, the initiators of such unwantedtraffic really want to send it, and will attempt to do so even if itrequires getting around limits and controls placed by the online networkoperator. This creates an “arms race” between the initiators of unwantedtraffic and the online network/systems operator.

There are many reasons a sender of unwanted traffic might want toinitiate the traffic. Often, those are financial reasons. For example,if a scammer can send out one million e-mails with a total expenditureof less than ten dollars and a half hour of time, and reap a few dollarsin profits from just 0.01% of the e-mail recipients, it iscost-effective for the scammer to do so. If an criminal organization canapply 100,000 username-password pairs to an e-commerce website to findthe 0.01% that are vulnerable, they would do so if the monetary returnsfrom hacking ten user accounts is greater than the cost to the criminalorganization of obtaining the username-password pairs plus the cost ofexecuting 100,000 attempted logins.

These unwanted attacks could be thwarted using guaranteed secure methodsto filter out unwanted/unauthorized traffic from wanted/authorizedtraffic. However, as illustrated from the examples above, even a 99.99%success rate at blocking attacks would still allow enough trafficthrough to be a cost-effective attack. Some of this economics comesabout because automation lowers the cost of transactions. Ironically,the very automation that makes it economically feasible for a bank,retailer, music distributor, online storage vendor, etc. to provide alow-cost service to millions of its customers also makes it economicallyfeasible for a criminal or criminal organization to make millions ofattempts to get at network resources in an unauthorized way.

If the effort required to mount an attack on a network resource can beraised so that it is uneconomical to attack (but still easy enough forauthorized users to access), the attacks might be reduced. Therefore, itwould be desirable to increase the efforts/costs of access to thenetwork resource in a way that makes it uneconomical for an organizationto mount an attack on network resources, while allowing authorized uses.

SUMMARY OF THE EMBODIMENTS

An API call filtering system filters responses to API call requestsreceived, via a network, from user devices. The API call filteringsystem is configured to require personalized API call requests whereineach API call (except for some minor exceptions) includes a uniqueendpoint identifier (“UEID”) of the user device making the request.Using the UEID, the web service or other service protected by the APIcall filtering system can be secured against excessive requestiterations from a set of rogue user devices while allowing for ordinaryvolumes of requests of requests the user devices, wherein one or moreboundaries between what is deemed to be an ordinary volume of requestsand what is deemed to be excessive request iterations are determined bypredetermined criteria.

The user device can be an endpoint device that executes endpoint apps,at least one of which sends requests via a network to a server orservice that has been secured against excessive request iterations froma set of rogue user devices while allowing for ordinary volumes ofrequests from user devices. Those requests are first processed by theAPI call filtering system. An example user device might comprise an appinitiator that processes data about, by, or for the user device, storagefor one or more UEIDs, wherein at least one UEID is associated with theuser device, and a request generator, that generates requests to be sentover the network to the service while identifying the user device in therequests.

Requests from user devices might include requests to authenticate theuser device with respect to a secured account maintained at or for theAPI call filtering system. Verification might be performed by having enduser devices generate a PM key pair, sending the public key portion ofthe key pair to the API call filtering system, thereby allowing the APIcall filtering system to verify a UEID by sending a challenge message tothe user device and receiving in return a signed message indicative of acase where the user device has a specific UEID.

The following detailed description together with the accompanyingdrawings will provide a better understanding of the nature andadvantages of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a swim diagram illustrating interactions of an example new appinitialization process.

FIG. 2 is a swim diagram illustrating interactions of an initialized apprunning on an endpoint computer system and a server servicing API callsfor that app.

FIG. 3 is a block/functional diagram illustrating several components ofprogram code that might interact to handle API servicing.

FIG. 4 is a block diagram of a networked computer system in which theprocesses and elements of FIGS. 1-3 might be used.

FIG. 5 is a block diagram of parts of FIG. 4 shown in greater detail.

FIG. 6 is a block diagram of a specific arrangement, wherein anout-of-band, address space limited domain technique is used to make ahigh-volume API attack impractical, infeasible, and/or uneconomical.

In the figures, like reference symbols in the various drawings indicatelike elements, and multiple instances of objects might be denotedparenthetically (e.g., 101(1), 101(2), . . . , 101(n)). Where numberedobjects in figures are shown with parenthetical sub-numbers ranging from0 or 1 up to some letter designation (e.g., “1, 2, . . . , k” or 1, 2, .. . , n”), it should be understood that the letter designationrepresents some finite number the value of which is not essential forthe understanding of the invention, unless otherwise indicated.

DETAILED DESCRIPTION

Network resources might include information, financial value, computingresources, or the like. For example, online-stored e-mails,online-stored personal photo, bank accounts with online transfercapability, online shopping services, computing power, etc., are allforms of network resources.

Network services might include uploading data, downloading data,interacting with server-side programs over a network, access to physicalresources (e.g., printers, cameras, other equipment, etc.),communication services, or similar services that might be provided overa network. Network services might be provided by an HTTP server coupledto a back-end data processing system, or the like. Other networkprotocols might be used, as appropriate.

The network can be the Internet, an intranet, an extranet, a LAN, WAN orsimilar network that connects computers/devices/systems at network nodesto at least some other network nodes, thereby allowing users to use thenetwork services.

As used herein, at least for the sake of readability, participants in atransaction might be referred to as a “user” and a “network serviceprovider” but it should be understood that these labels might sometimesrefer to humans or computers as users and/or persons, business groups,organizations, etc. as network service providers, even thoughspecifically and technically it may well be that an electronic deviceoperated by, or at the behest of, a user is what is doing theinteraction and the interaction is with computer/electronic hardwareoperated by, or at the behest of, a network service provider.

Electronic user devices might include computers, tablets, wearablecomputer devices, smartphones, embedded computer systems, or otherdevices.

Also, for the sake of readability, explanations are provided in thecontext of a user/user device running an “app” that interacts over thenetwork with a server where the app and the server are coordinated suchthat the way the app interacts with the server is at least familiar tothe server and vice versa. Unless otherwise indicated, the app can be aprogram running at the user device in user space, in system space, inbrowser space, etc. and can be a simple or complex program with ageneral or specific purpose. Thus, the “app” designation herein is not,unless otherwise indicated, limited to specific types of programs.

Most often, network resources are constrained so access to those networkresources should be limited to those users and user devices that areauthorized to access those resources and mechanisms would be used toblock unauthorized access to those resources, or at least thwartunauthorized access enough to make it uninteresting to those persons ororganizations that would attempt unauthorized access. Common examples ofnetwork resources that are constrained might include a messaging(e-mail, text, etc.) server that sends, stores, retrieves messages, someof which are not intended to general viewing, or an online bankingapplication that might provide access to confidential financialinformation and the ability to transfer funds or obligate an accountowner in some way.

One approach to this dichotomy—one that makes it easy for authorizedusers to get in and access those network resources, but makes it hardfor unauthorized users to do so—is to make it so that both authorizedusers and unauthorized users have to manually interact with the securitysystem that protects a network resource. For example, a webserver andsystem that allows users and user devices to initiate transactions totransfer money, purchases, or other markers of value from the systemoperator to the control of the initiator will want to control access. Asa specific example, an online clothing retailer might allow anyone toshop online and cause products to accumulate in an online “shoppingcart” but then before the transaction is consummated, the user isauthenticated, necessary financial details are made, and the user isrequested to pass a Turing test (such as a CAPTCHA test), to thwartattempts to automatically attempt to purchase goods using a large numberof purloined username-password pairs.

While in some cases this is an easy feature to provide, in other casesit is not so straightforward. For example, where there is direct userinteraction, the user interface can be such that it requires a humanuser to interact with the user interface in order to accomplish a task.While that might be good for thwarting automated attacks, it would alsoblock legitimate automated actions. Moreover, introducing additionalsteps that require user interaction may discourage legitimate users,which can decrease the usefulness of the service offered and oftendirectly impact the revenue of the service provider.

Suppose a bank provides a way for friends to transfer small amountsamong themselves and that way is to have each person call a call centerand describe the details of the desired transaction to a call centeroperator. That is likely to be infeasible. It is more feasible to havethe transaction done entirely by the user interacting with a computersystem, such as a website that allows users to transfer small amounts ofmoney. Since it is expected that individual users would manually beaccessing the website (and that unauthorized organizations would attemptautomated programmatic access to the website), by only allowing directwebsite interfacing, the unauthorized access can be made more difficult(and thus less cost-effective).

This works well, until users and network resource managers decide thatthey want to allow for some interaction that is not manual. For example,suppose five friends are playing an online poker game for real money.When one friend wins a hand, the others would transfer some small amountto the winner. If the only way to transfer funds is for pairs of playersto manually interact with the network resource that manages the fundstransfers, this can be cumbersome. At the end of each hand, the playerswould stop, look at the online poker game program to determine how muchthey won/lost and to whom, and then look to a financial transfersprogram to make the corresponding transactions.

Rather than require each of the players to manually navigate a moneytransfer program interface each hand, the online poker game might handlethat process directly by sending commands to indicate transfers aftereach hand. Typically, this might be done using an applicationprogramming interface (“API”), wherein non-human programs are given astructure to create interactions with the network resource in expectedand authorized ways. But then this may then create a problem withunauthorized automated network access.

In some ways, it might be easy to describe transactions and interactionsthat are legitimate and those that are not legitimate. For example, atransfer of 25 cents every few minutes from Alice's poker funds accountto Bob's poker funds account might be a legitimate set of transactions.Carol attempting to log in to her poker funds account three times mightalso be a legitimate set of transactions. Attempted transfers of $100every fifteen seconds would not be a legitimate set of transactions foran online poker game among friends, nor would logging in to the pokersystem using Carol's credentials and trying 10,000 possible passwords.

Some times this filtering is hard and sometimes it is easy. One aspectof filtering that would make it easier to separate the authorizedaccesses from the unauthorized accesses is to identify and flagbehaviors that seem unauthorized. This has been done extensively in thecredit/debit card market, where card issuers have automated systems thatstudy patterns to detect potential fraud. This would prevent a criminalfrom stealing a credit card from someone who only uses the card to buygroceries once a week and using that credit card to buy expensivejewelry twice a day. Obviously, the simplest computer program can flagthat fraud and block the jewelry purchases. Unfortunately, criminals andespecially sophisticated criminal organizations know this and have foundways to work around those blocks.

A criminal organization might purchase a dataset of a large number ofcredit card numbers and then automate the use of each credit card for asmall purchase (that might later be converted to cash in the hands ofthe criminal organization) and get around fraud protections. Asexplained herein, those situations can be dealt with by having somelimited resource that does not appear limited for authorized users butdoes appear limited for unauthorized automated attackers. As an example,each device that is connected to a secured network resource might beallowed a set number of accesses in a time period (e.g., 20 accesses perday per device, 1 access per five minute period, etc.). Unauthorizeduser devices that are relying on automation to make millions of accessesper day would be blocked.

Unfortunately, again, criminal organizations know this and might routearound the blockage by having the unauthorized user device falsifyinformation sent to the network resource so that the network resourcesees a million accesses as coming from a million different user devices.

This document describes systems and techniques for weakly or stronglyidentifying specific end-user devices and their interfaces, despite theknowledge known to the attackers, and thereby thwarting attacks. Inparticular, attacks mounted by unauthorized users and/or their devicesusing automated programs to replace human interaction with programs/apps(commonly referred to as “bots”).

FIG. 1 is a swim diagram illustrating interactions of an example new appinitialization and use process for an endpoint app. In this example, theendpoint app is assumed to be an application installed on a user devicesuch as smartphone or tablet. Examples of user devices includesmartphones or tablets running the iOS™ operating system or the Android™operating system and can include devices that obtain apps solely througha centralized repository of apps as well as those that obtain appsthrough other channels. The endpoint app might be obtained directly froma user operator or might be obtained from a centralized repository ofapps. Examples of centralized repository of apps include the App Store™app repository operated by Apple Computer and the Google Play™ appmarketplace.

In step 102, the endpoint app is installed. The endpoint app in thisexample is modified to add uniquely identified API calls, such that theAPI call identifies the particular instance of the endpoint app. Inother variations, those uniquely identified API calls might be native,built-in, and/or preexisting rather than modified. Where the endpointhas an original (non-unique API call protocol) API and a modified,uniquely identified API call protocol API, it may be that the necessarymodifications occur by changing a library used by program code, such asa library linked at compile time. As explained later in this example,since endpoint app and an API call filtering system (herein, a“botwall”) are configured such that each user device is initialized withrespect to the botwall before the endpoint app provides originalintended functionality, this can happen when the app first startsexecuting.

In step 104, the user device (or operating system or other codeexecuting on the user device for this purpose) determines whether theendpoint app has been used before or if this is the first use of theapp. If so, flow proceeds to step 106. It may be that the endpoint apphas been used before, but perhaps on a different hardware platform or itwas deleted and restored, but in some of those cases, the endpoint appis treated as not having been run before.

In step 106, the endpoint app or the user device generates or obtains aunique endpoint identifier (“UEID”) 105 to be associated with thatinstance of the endpoint app. Various subprocesses for generating UEIDsare described hereinbelow. Once generated, the UEID 105 is transmittedto the botwall (step 107) as well as being stored local to the userdevice (step 108). Once this initialization process is complete, theuser device has a UEID to associate with that instance of the endpointapp (and that UEID might persist across changes of user device, IPaddress, configurations of hardware, etc.) and the botwall has the UEIDassociated with that instance of the endpoint app.

In some variations, the UEID is created at the botwall upon request bythe endpoint app or the user device and the UEID is sent from thebotwall to the user device. In those variations, the user device neednot send the UEID to the botwall as the botwall would have retained acopy. In some embodiments, the UEID is sent as a secured payload so thatinterlopers cannot discover it or alter it to their benefit.

In this example of FIG. 1, it can be assumed that the user device hasnot previously run or initialized the endpoint app, or has been reset,wiped, or reconfigured to appear to have not previously run orinitialized the endpoint app. It should be understood that theinstallation/use of the example endpoint app described in detail can beindependent of the installation/use of other apps on the user device.While some user devices might be configured to execute one and only onededicated app, other user devices might be configured to run as manyapps as the user choses, subject to storage constraints.

Subsequent API operations between the endpoint app and the web serviceare tagged the UEID. The API messages are intercepted by the botwall andif the UEID is valid it is striped from the message and then message isforwarded to the original web service or supporting server, as will beexplained with the flow proceeding to step 120. If the endpoint app isinstalled and it is determined that the endpoint app has already beeninitialized, flow passes to step 114, where the UEID is read by theendpoint app (and/or its library) and flow passes to step 120.

By personalizing the API for each endpoint, by requiring the UEID beappended for each API call, the botwall can count the number of APIcalls from each unique endpoint. For example, a dozen attempts toauthenticate from one endpoint during one day might be normal, but athousand is clearly not an appropriate use of a single endpoint and ismost likely and iterative kind of attack. The count of legitimate andthe illegitimate uses of API calls are likely to differ by orders ofmagnitude. To protect the UEIDs from being reasonably guessed by theattacker, the UEID protection could be based on probability (i.e., alarge random number).

At step 120, when the endpoint app initiates an API call request 123, itmakes the call using the UEID as one of its arguments and sends ittoward the botwall and/or the supporting service). The botwall in turnwill test the UEID for validity, log the UEID and API call request, andstrip out the UEID to form a different API call request 127 that is senttowards the API supporting service. Where the botwall tests the UEID forvalidity and finds that it is not valid, determines that the API callvolumes for the UEID are above a threshold between normal use andunauthorized use, or the like, the botwall can block, drop or alter theAPI call request. In some cases, API call request 127 is identical toAPI call request 123, but in preferred implementations, API call request127 is not UEID-specific and API supporting services that areUEID-unaware will process API calls correctly. In some implementations,exceeding a permitted API call volume would trigger the botwall todelete the associated UEID from the botwall's list of valid UEIDs.

If the botwall does pass API call request 127, the supporting service(such as a set of servers programmed to support a particular API, usingHTTP or other protocol) would receive the API call (step 130) and fieldthe API call by generating and returning (step 132) the appropriate callresponse 135 to the endpoint app, which would then continue processingas programmed (step 140). This process would be repeated as often asneeded.

FIG. 2 is a swim diagram illustrating interactions of an initializedendpoint app running on an endpoint computer system (such as a userdevice) and a supporting server servicing API calls for that app withadditional steps. As the user device is executing the endpoint app, theendpoint app's program code might reach a point where the endpoint appwants to make an API call toward the supporting server, where it will beintercepted by the botwall. Alternatively, the endpoint app might directall API calls directly to the botwall. The endpoint app would thengenerate the API call (step 202) and send an API call request 203 to theappropriate place (in FIG. 2, this is illustrated as being the botwall,but it could be otherwise). API call request 203 would include the UEIDas well as any arguments required by the API call.

Once the API call request is received by the botwall, the botwall makesa note of the UEID (step 204) and then issues (step 205) a challengemessage 207 to the user device/endpoint app. One purpose of thischallenge message is so that the botwall can authenticate that the userdevice is the device associated with the proffered UEID. The user devicereceives the challenge message (step 208), prepares a response message211 and sends the response message 211 to the botwall (step 210). Theresponse message 211 is such that it contains information that could nothave easily been generated apart from the endpoint app that isassociated with that UEID.

The botwall then authenticates the response message (step 212). If theresponse is valid, thus indicating that that endpoint app is indeedassociated with that UEID, the botwall notes (step 214) the instance ofuse of that API call with that UEID and forwards the API call (possiblywith the UEID still included, or removed) toward the supporting server.If at step 214, the botwall determines that the UEID is not valid, thebotwall can choose not to reply to the API call request.

In other variations, the API supporting server and botwall are moretightly integrated, such as being on the same machine or usingintermingled code. However, this may require modifications of the APIsupporting server. For example, the filtering process for API callscould be built directly into the supporting service system.

In the manner described above, API calls, even though automated, can belimited. For example, it might be acceptable to accept up to tenlogin/authentication API request messages related to one user device ina short period of time, but it typically not acceptable to field tens ofthousands of login/authentication API request messages from a given userdevice.

In a specific embodiment of a botwall, the challenge is a random numbergenerated by the botwall that the endpoint app (or user device) thenencrypts using a private key of a public/private key pair associatedwith that UEID. The response is sent to the botwall, which then decryptsthe challenge response using the previously stored public key of theUEID/app. If the decrypted challenge response includes the random numberthat the challenge message included, as well as the correct UEID, thebotwall should be able to safely assume that the correct endpointapp/user device performed that action, as the private key should onlyexist in the context of that endpoint app. If the endpoint app/userdevice fails the challenge, the botwall might just discard the rest ofthat transaction.

Even if the challenge response is successful, since the botwall has theUEID for each API call that uses these features, transaction volume canbe measured and where a rational rate is exceeded (e.g., a rate thatwould be allowed for ordinary users), the botwall might drop that APIcall and delete/forget the UEID and its associated public key, thusinvalidating future UEID-based API calls from that endpoint app (until anew UEID is generated at least).

In some variations, not all API calls are required to include the UEID,but where it is included, the botwall can easily correlate transactionrequests with UEIDs. The botwall can do this even while user devicefingerprints change (e.g., when one user gets a new user device, adevice is restarted, when an IP address changes, etc.).

Of course, some determined hackers could delete the app, redownload it,and start the initialization process, thereby getting a new UEID. Sincea legitimate user might only get an additional new UEID when purchasinga new user device, limits on the frequency or volume of new UEIDs wouldnot burden legitimate users, but would thwart hacking attempts that usea small number of devices to make a large number of API calls and try tobypass the speed controls, as the hacking attempt would involve attemptsto generate many orders of magnitude more UEIDs than are legitimatelyneeded.

To block unauthorized access by an unauthorized person while notencumbering legitimate users of an API service, a threshold might be setfor the number, frequency, location, etc. of new UEID registrations. Thethreshold does not need to be fixed, or exact, as the difference betweenthe two cases is typically quite wide.

A typical credential stuffing attack might take 1,000,000username-password pairs, known to work on other web sites, and test themon the target of interest in an attempt to discover where thecredentials have been reused. Whereas a typical accidently incorrectpassword entry by a legitimate user might result in less than ten triesof username and password, the attack needs at least thousands ofiteration to be minimally effective. As explained herein, one approachof prior art might attempt remediation by applying rate limits on the IPaddress. For example, once an app server receives 100 login attemptsfrom one IP address the app server can block all further traffic fromthat IP address or endpoint device. Without more, this might also blocklegitimate users (suppose the IP traffic from hundreds of legitimateusers is routed through one IP address such as occurs in the officeenvironment of a large company) and further this approach might allowattackers to pass, if they route their traffic through multiple proxiesto make it appear that one device is actually many different devices.Another approach of prior art is to limit rates associated with a device“fingerprint” which is certain properties about the device such as thetype of browser, operating system version, clock skew, etc. The outcomeis the similar to rate limiting by IP address, attackers simply alterthe fingerprint to other obviously valid permutations.

As explained herein, to prevent (or at least encumber) a hacker fromspoofing the botwall to hide the fact that a large number of usercredential uses are coming from the same endpoint app, endpoints areuniquely identified. To prevent (or at least encumber) a hacker fromresponding by having endpoints generate new UEIDs for every iteration ofthe attack or for every few iterations, the UEID generation process canbe tied to some subprocess that works well for small numbers, but notwell for large numbers.

One example of such a subprocess is to tie the UEID generation to aspecific IP address. This can be a soft barrier. Suppose that each timesome user device sends in a new UEID and public key pair, the botwallrecords the IP address from which the request came. That way, if volumesexceed rational rate thresholds, then requests from the associated IPaddresses might be subject to additional scrutiny for a time period, ora non-automatable step is imposed on the user.

It might be that the botwall includes a non-automatable step for everyUEID generation. While this would add an extra step even for legitimateusers, they would not see that extra step that often, perhaps only whenswitching to a new user device. That non-automatable step might involvea web page that is configured to block/frustrate automated interactionwith that web page.

In another approach, the botwall performs an in-band or out-of-band stepthat makes use of an address space limited domain. As an example, auser's telephone number can be verified by an out-of-band process ornon-automatable step. If the botwall required each request forregistration of a new UEID to include the UEID, the public key, and avalid telephone number in the custody of the user, the app server couldverify that telephone number by sending an SMS message to that number,placing an IVR call to that number, etc., and waiting for a userresponse.

The app server need not be hardcoded to reject multiple requests fromthe same telephone number, as that might typically happen when multiplelegitimate users are sharing a telephone number or a user gets a newuser device without a new telephone number. However, the app server canbe coded to reject large numbers of requests from a given telephonenumber. Since a criminal organization performing some network attacksvia an automation of API calls would likely need to execute a largevolume of API calls (in part to account for a very low hit rate), theywould be blocked from large scale automation in part by the fact thattelephone numbers comprise an address space limited domain (inparticular, the address(es) available to the attacker). Thus, with UEIDregistration requests each being correlated with a verifiable telephonenumber, attackers might not be able to obtain enough telephone numbersto produce sufficient different UEIDs to allow the attackers to runsufficient number of automated iterations. Telephone numbers associatedwith excessive iterations might be temporarily or permanentlyblack-listed.

Tying the registration of new UEIDs to the possession of a telephonenumber creates a supply problem for the attacker, but not the legitimateuser. This is because all legitimate users possess telephone numbers insufficient quantity to register for any rational use. All attacksrelying on iteration are deficient, by orders of magnitude, a sufficientquantity of unique telephone numbers to create valid registrations. Thetying of registrations to telephone numbers could be implemented in ormore of several ways. For example, the registration might involve an IVRtelephone call to the user wherein the app server sends the user anaccess code over the network channel and prompts the user to enter thataccess code into the telephone. The app server might just request anyresponse, which would block attackers that are not able to feasiblyreceive and respond to tens of thousands of telephone calls.

As explained herein, in effect, the API usable by each user device ispersonalized to that user device and automating volume requests thatshould not be in volume are filtered out because too many come from oneUEID/user device. If there are limits to the rate at which UEIDs can becreated, then it can become infeasible for an attacker to bypass thefiltering by rapidly changing the UEID or spoofing it. Thus, bypersonalizing each API, the attacker cannot run sufficient iterationsthough one API case or find/generate enough API cases to support theiterations required for a successful attack.

This can be used apart from, or in combination with, polymorphic objectcode procedures.

An API iteration attack relies on high iterations of amachine-to-machine (“M2M”) API. Since it is often a simple matter toreverse-engineer and understand an M2M API interface, the attacker canmasquerade as any expected device/application simply by exhibiting thecorrect behavior while exercising the API. Because of the use of Wi-Fifor mobile device communication, and other reasons, IP addresses alonemight not be a useful way to identify real mobile devices. However, atypical attack that expects to create value by exercising an APIiteratively will need millions of iterations to scale to the point whereit can be sufficiently monetized to justify the attention of criminalenterprise and to produce losses worth mitigating. Through a combinationof limiting the number of API calls from one user device and limitingthe number of UEIDs that can be assigned, this attack is likely renderedinfeasible.

The initialization process could be transparent or semi-transparent tothe user. For example, once the user installs an app that is protectedwith the personalized API, and runs the app for the first time, theendpoint app can obtain the UEID and verify the smartphone's telephonenumber, all without user interaction. A message to the botwall might bein the form of an SMS sent via commonly available API's for smartphoneapps. Short messages are correlated to network part of the transactionand the telephone number of the user device can be obtained from theinbound SMS header.

Where it is possible to spoof the telephone number in the SMS header,added security might be provided by having the botwall sends a challengenumber via SMS to the telephone number provided. Using the SMS API, theendpoint app can capture this number and send it back to the app server.This might use a type 0 SMS (silent) message so not to disturb the user.

In other variations, a transparent wrapper is used to wrap native appobject code with more object code and intercept outbound socketconnections. That connection might be directed to a botwall.Anti-automation protocol is settled first and then traffic is routedfrom the botwall to the web service, which sees the API as it waspreviously expected. In yet other variations, the native app developerincorporates a library instead of wrapping object code. In somevariations, there is a separate endpoint app for handling the processesof initialization and/or personalization and the native app calls thatseparate app. This might allow for more than one protected native app toshare a single validation/registration, as well as correlating behaviorover multiple apps.

Where the user device is a desktop computer, tablet, or the like, thatdoes not have an assigned telephone number, the same approach could betaken by correlating with any telephone number in the possession of theendpoint app user, perhaps by the IVR method described herein, separatefrom the user device.

For publicly exposed APIs, an anti-automation library might be providedto the API user to do the endpoint device side part of the APIpersonalization problem. Registrations might then be handled by aspecial web page flow on the API provider's site and may also correlateregistrations with any telephone number using the IVR method.

For some web sites that cannot accommodate other defenses, thepersonalized API methods and apparatus described herein might be usedwhere the UEID is generated at on a specific web page created to blockautomation and then the UEID is validated on all subsequent web pages.

FIG. 3 is a block/functional diagram illustrating several components ofprogram code that might interact to handle API servicing. FIG. 3 showsendpoint app code 302, as might be executed by a user device, app servercode 304, as might be executed by, or as part of, a web server or otherapp server, with endpoint app code 302 including API interface code 306and server app code 304 including API interface code 308. The APIinterface code portions 306, 308 might interact with each other over theInternet.

As illustrated in FIG. 3 and elsewhere, endpoint app code 302 includesfunctionality to obtain and store a UEID for the user device that isexecuting endpoint app code 302. During execution, when the userdevice's processor encounters an API call (illustrated in FIG. 3 as“x=apicall(getuserdata, UEID, ARGs)” as an example), that code calls APIinterface code 306, which in turn performs one or more of the processesdescribed herein to interface to the botwall. Once the apicall( )function returns a value or values from the supporting service, theendpoint app can use that information.

App server code 304 might include separate code sections for code 310 tocheck UEID usage and apply throttling as deemed appropriate, and code312 for API handling if code 310 allows an API request from an endpointdevice to pass.

FIG. 4 is a block diagram of a networked computer system in which theprocesses and elements of FIGS. 1-3 might be used. As illustrated there,a networked computer system 400 comprises one or moreclient/endpoint/user devices 402 operated by users (and some attackers,possibly) to interface to one or more API supporting servers 404 via anetwork 406. Networked computer system 400 includes at least one botwall408 and a maintenance and administrative console 410, each of whichmight be able to communicate via network 406. Servers 404 might becoupled to data stores 412. In another variation not shown, botwall 408and server 404 are connected such that all traffic to and from server404 has to pass through botwall 408.

FIG. 5 is a block diagram of parts of FIG. 4 shown in greater detail,but for only one endpoint device and one supporting server. As shownthere, an endpoint device 502 communicates with a secured API supportingservice 504 that is secured against a high-volume automated API attackusing methods and apparatus described herein, and also communicates witha botwall 508. The communication shown is via a network 506, butadditional paths, as explained elsewhere herein, might be used. Securedservice 504 might provide endpoint device 502 with access to data store510 and/or other networked resources.

A user device or app server, etc. might include various components. Forexample, a user device might comprise a central processing unit (“CPU”),random access memory, storage for data values such as a private key andan UEID, a network interface and an input/output interface. A system busmight connect the various components.

Typically, the CPU capable of processing instructions for execution thatit reads from program code storage, which might be RAM, ROM, flash,magnetic storage, etc. The CPU may be designed using any of a number ofarchitectures, such as a CISC (Complex Instruction Set Computer)processor, a RISC (Reduced Instruction Set Computer) processor, or aMISC (Minimal Instruction Set Computer) processor. The CPU might be asingle-threaded processor or a multi-threaded processor. Additionalfunctionality might be provided by a graphics I/O system and processor.

In some implementations, the memory used is a computer-readable medium,such as a volatile memory unit or a non-volatile memory unit. Variousstorage devices might be capable of providing mass storage for variousneeds. For example, in one implementation, storage devices compriseflash drive devices, floppy disk devices, hard disk devices, opticaldisk devices, tape devices, or the like.

Input/output devices might include a keyboard and/or pointing device anda display unit for displaying graphical user interfaces.

The features described can be implemented in digital electroniccircuitry, or in computer hardware, firmware, software, or incombinations of them. The apparatus can be implemented in a computerprogram product tangibly embodied in an information carrier, e.g., in amachine-readable storage device for execution by a programmableprocessor; and method steps can be performed by a programmable processorexecuting a program of instructions to perform functions of thedescribed implementations by operating on input data and generatingoutput. The described features can be implemented advantageously in oneor more computer programs that are executable on a programmable systemincluding at least one programmable processor coupled to receive dataand instructions from, and to transmit data and instructions to, a datastorage system, at least one input device, and at least one outputdevice.

A computer program is a set of instructions that can be used, directlyor indirectly, in a computer to perform a certain activity or bringabout a certain result. A computer program can be written in any form ofprogramming language, including compiled or interpreted languages, andit can be deployed in any form, including as a stand-alone program or asa module, component, subroutine, or other unit suitable for use in acomputing environment.

Suitable processors for the execution of a program of instructionsinclude, by way of example, both general and special purposemicroprocessors, and the sole processor or one of multiple processors ofany kind of computer. Generally, a processor will receive instructionsand data from a read-only memory or a random access memory or both. Theessential elements of a computer are a processor for executinginstructions and one or more memories for storing instructions and data.Generally, a computer will also include, or be operatively coupled tocommunicate with, one or more mass storage devices for storing data.Storage devices suitable for tangibly embodying computer programinstructions and data include many forms of non-volatile memory,including, by way of example, semiconductor memory devices, such asEPROM, EEPROM, and flash memory devices, magnetic disks such as internalhard disks and removable disks, magneto-optical disks; and CD-ROM andDVD-ROM disks.

The processor and the memory can be supplemented by, or incorporated in,ASICs (application-specific integrated circuits). To provide forinteraction with a user, the features can be implemented on a computerhaving a display device such as a CRT (cathode ray tube) or LCD (liquidcrystal display) monitor for displaying information to the user and akeyboard and a pointing device such as a mouse or a trackball, or atouchscreen, by which the user can provide input to the computer.Additionally, such activities can be implemented via touchscreen flatpanel displays and other appropriate mechanisms.

The features can be implemented in a computer system that includes aback-end component, such as a data server, or that includes a middlewarecomponent, such as an application server or an Internet server, or thatincludes a front-end component, such as a client computer having agraphical user interface or an Internet browser, or any combination ofthem. The components of the system can be connected by some form ormedium of digital data communication such as a communication network.Examples of communication networks include a local-area network (“LAN”),a wide-area network (“WAN”), peer-to-peer networks (having ad-hoc orstatic members), grid computing infrastructures, and the Internet.

FIG. 6 is a block diagram of a specific arrangement, wherein anout-of-band, address space limited domain technique is used to make ahigh-volume API attack impractical, infeasible, and/or uneconomical. Asillustrated there, a user device 602 (such as a smartphone) interactswith a botwall 604 over a network 606, performing calls to an API servedby botwall 604. Botwall 604 expects API calls to be personalized so thatthe user device (or some proxy of the user device) can be identified, sothat botwall 604 can block calls that are beyond what a reasonable,legitimate user device would make. User device 602 might initializeitself to support a UEID and PM pair through network interactions orthrough out-of-band interactions, such as a telephone call throughtelephone system 610.

The computer hardware described herein might be used with the computersoftware described herein unless otherwise indicated. The software canbe written in one or more languages and be stored in different forms ofmemory or storage. The computer hardware described and illustrated mightinclude various forms of digital computers, such as laptops, desktops,workstations, personal digital assistants, servers, blade servers,mainframes, and other appropriate computers.

The user device might include mobile devices, such as personal digitalassistants, cellular telephones, smartphones, and other similarcomputing devices. Additionally the system can include portable storagemedia, such as Universal Serial Bus (“USB”) flash drives. For example,the USB flash drives may store operating systems and other applications.The USB flash drives can include input/output components, such as awireless transmitter or USB connector that may be inserted into a USBport of another computing device.

The computer system can include clients and servers. A client and serverare generally remote from each other and typically interact through anetwork. The relationship of client and server arises by virtue ofcomputer programs running on the respective computers and having aclient-server relationship to each other. An endpoint device is a devicethat connects, in some manner, to at least one of the servers, directlyor indirectly, to perform some end goal. Where one device is designatedas an endpoint device, it may be that that endpoint device is a clientin some client-server relationship, but it could also be a server insome instances and there may be intermediaries that are treated asclient-server combinations.

While this specification contains many specific implementation details,these should not be construed as limitations on the scope of anyinventions or of what may be claimed, but rather as descriptions offeatures specific to particular implementations of particularinventions. Certain features that are described in this specification inthe context of separate implementations can also be implemented incombination in a single implementation. Conversely, various featuresthat are described in the context of a single implementation can also beimplemented in multiple implementations separately or in any suitablesubcombination. Moreover, although features may be described above asacting in certain combinations and even initially claimed as such, oneor more features from a claimed combination can in some cases be excisedfrom the combination, and the claimed combination may be directed to asubcombination or variation of a subcombination.

Other implementations are within the scope of the following claims.Similarly, while operations are depicted in the figures in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the implementations described above should not beunderstood as requiring such separation in all implementations, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

In some cases, the actions recited in the claims can be performed in adifferent order and still achieve desirable results. In addition, theprocesses depicted in the accompanying figures do not necessarilyrequire the particular order shown, or sequential order, to achievedesirable results. In certain implementations, multitasking and parallelprocessing may be advantageous.

Further embodiments can be envisioned to one of ordinary skill in theart after reading this disclosure. In other embodiments, combinations orsub-combinations of the above disclosed invention can be advantageouslymade. The specification and figures are, accordingly, to be regarded inan illustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims and that the invention is intended to cover allmodifications and equivalents within the scope of the following claims.

What is claimed is:
 1. An API call filtering system that filters APIcalls received, via a network, from user devices that arenetwork-connected and running endpoint app software and/or hardware, tosecure an API service that accepts API call requests and provides APIcall responses thereto, wherein the API service is secured againstexcessive request iterations from a set of rogue user devices whileallowing for ordinary volumes of requests of the user devices, whereinone or more boundaries between what is deemed to be an ordinary volumeof requests and what is deemed to be excessive request iterations aredetermined by predetermined criteria, the API call filtering systemcomprising: a request handler, coupled to a network interface, forhandling requests from user devices; an end-point identifier, coupled tothe request handler, for determining an identity of a requesting userdevice based on a personalized application programming interface (“API”)processing of a received request; storage for a plurality of referencesto user devices, references to their corresponding unique endpointidentifiers (“UEIDs”); a verifier for verifying with the requesting userdevice that it is the user device associated with the UEID included inthe request from the requesting user device; and a filter controller fordropping, filtering and/or forwarding requests for ordinary volumes ofrequests, wherein the filter controller operates, at least in part, byrecognizing the UEIDs of the requests, thereby allowing filtercontroller to filter out excessive requests from unrecognized userdevices and user devices that are issuing what is deemed to be excessiverequest iterations.
 2. The API call filtering system of claim 1, whereinrequests from user devices include requests to authenticate the userdevice with respect to a secured account maintained at or for the APIservice.
 3. The API call filtering system of claim 1, wherein theverifier for verifying includes a public key module that can encrypt achallenge message using a public key of a public key pair associatedwith one or more UEIDs and check signing of challenge reply messages. 4.The API call filtering system of claim 3, wherein the challenge messageincludes a random, semi-random, or pseudorandom number.
 5. The API callfiltering system of claim 1, wherein one or more of the request handler,the end-point identifier, the storage for a plurality of references touser devices, the verifier, and/or the filter controller are integratedinto the secured API service.
 6. A user device that executes at leastone endpoint app that sends API requests via a network to an API servicethat has been secured against excessive request iterations from a set ofrogue user devices while allowing for ordinary volumes of requests fromthe user devices, the user device comprising: an app initiator thatprocesses data about, by, or for one or more endpoint apps that executeon a user device; storage for one or more UEIDs, wherein at least oneUEID is associated with the one or more endpoint apps; and a requestgenerator, that generates requests to be sent over the network to an APIcall filtering system and/or an API service while identifying theendpoint app in the requests.
 7. The user device of claim 6, whereinUEIDs are associated with a limited address space to reduce an abilityof an unauthorized device to use multiple UEIDs in order to hide asource of excessive request iterations.
 8. The user device of claim 7,wherein the limited address space is provided by association of UEIDrequests with telephone numbers.
 9. The user device of claim 6, furthercomprising storage for a private key of a public key infrastructure(“PKI”) key pair, wherein the private key used at least to encryptchallenge responses thereby signaling that the user device has access tothe private key.
 10. The user device of claim 6, wherein the requestsgenerated by the request generator are requests directed to be sent overthe network to the API call filtering system.
 11. The user device ofclaim 6, wherein the requests generated by the request generator arerequests directed to be sent over the network to the API service.
 12. Ina secured network environment, wherein a computing system that servicesapplication programming interface (“API”) calls is connected to anetwork that allows for authorized user devices to initiate such APIcalls and also allows for unauthorized user devices to initiate such APIcalls, a method of detecting at least some unauthorized API calls, themethod comprising: receiving, over the network, an API call from a userdevice; identifying an end-point identifier supplied by the user devicebased on data provided with the API call; checking that end-pointidentifier against a stored plurality of references to user devices'corresponding unique endpoint identifiers (“UEIDs”); verifying that therequesting user device is the user device associated with the UEIDincluded in the request from the requesting user device; and filteringout API call requests, based on the UEID and its determined validity.13. The method of claim 12, wherein filtering out requests comprisessecuring the API call requests against excessive request iterations froma set of user devices while allowing for ordinary volumes of requests offrom the set of user devices, wherein one or more boundaries betweenwhat is deemed to be an ordinary volume of requests and what is deemedto be excessive request iterations are determined by predeterminedcriteria.
 14. The method of claim 13, wherein securing the API callrequests against excessive request iterations comprises droppingrequests using invalid UEIDs, dropping requests for a given UEID thatare deemed excessive requests, and forwarding requests for ordinaryvolumes of requests from valid UEIDs.
 15. The method of claim 12,wherein at least one of the API calls authenticates user devices withrespect to a secured account maintained by the API service.
 16. Themethod of claim 12, wherein verifying comprises: encrypting a challengemessage using a public key of a public key pair associated with one ormore UEIDs; and checking digital signatures of challenge reply messages.17. The method of claim 16, wherein the challenge message includes arandom, semi-random, or pseudorandom number.